Batch up power level event when creating rooms #14070
Conversation
…vent are present in the batch and if so, pass them to the auth functions
… pass batch of events to _get_power_levels_and_sender_level
…rger body size due to batched events
There was a problem hiding this comment.
This seems reasonable to me at first glance.
Though a point I wanted to check:
are these events persisted in a chain that all point to each other? I thought selecting the prev_events would happen in create_event, which seems to be happening before the events get persisted...
(Is there a test around that tests that the events created when creating a room are a chain?)
(edit: just thinking that it seems quite important for the power levels event to come before the others)
It also looks like you've collided with the push rules evaluator port to Rust, so a big chunk of your changes need porting :(
|
I think it might be helpful to split the batching up of push rules into a separate PR too? A quick glance looks like there are a few different things going on in here. |
The events are indeed persisted in a chain pointing to one another. While there is not an explicit test verifying this, a number of existing tests implicitly rely on this behavior and break in arcane ways when this assumption is violated. I discovered this early on in the process of batching up the events, when I devised a solution which branched the dag (which is not the solution that landed). Currently, the |
|
Right I've split up this PR, the first half deals with the auth events and is here: #14214. Once that's approved I will put up a PR dealing with the push rule changes and adding the initial power level event. |
|
The second half is at #14228 |
Follow on work from #13800. Add the initial power level event to the group of events that are batch persisted when the room is created. Reviewable commit-by-commit.